Computerized devices control almost every aspect of our life—from writing documents to controlling traffic lights. However, computerized devices are bug-prone, and thus require a testing phase in which the bugs should be discovered. The testing phase is considered one of the most difficult tasks in designing a computerized device. The cost of not discovering a bug may be enormous, as the consequences of the bug may be disastrous. For example, a bug may cause the injury of a person relying on the designated behavior of the computerized device. Additionally, a bug in hardware or firmware may be expensive to fix, as patching it requires call-back of the computerized device. Hence, many developers of computerized devices invest a substantial portion of the development cycle to discover erroneous behaviors of the computerized device.
During the testing phase, a sample of all possible behaviors of the computerized device, also referred to as a System Under Test (SUT), is inspected. Dynamic verification which stimulates the SUT and is used to identify bugs may be utilized. Generally, Dynamic verification is associated with the execution of the SUT (or simulation thereof), and dynamically checks its behavior. As opposed to static verification measures which analyze the SUT without executing it, such as model checking, formal verification, static code analysis, or the like. Dynamic verification may any of the following: test planning, test-generation, SUT simulation, testing of the SUT, coverage analysis, or the like.
Coverage tools for checking software provide a measure of how well the software being evaluated has been exercised during testing and thereby give a level of assurance that the software is of high quality.
There are a number of types of coverage known in the art, such as statement coverage, line coverage, condition coverage, path coverage, method coverage, and the like. One additional coverage method is functional coverage. Functional coverage is designed to measure amount, portion or a similar metric of tests that examined predetermined functional behaviors. Once functional coverage is measured, quality assurance (QA) personnel may design additional tests to examine untested behaviors.
A functional coverage is measured with respect to a functional coverage model. The functional coverage model defines a triplet: functional attributes, a domain for each functional attribute, and a set of restrictions. The functional attributes may be any attribute of the SUT, such as for example a type of web browser being used, an underlying Operating System, a number of threads operating, whether the output was printed. The domains may define for each attribute a set of possible values. For example, the web browser may be Microsoft® Internet Explorer®, Google® Chrome®, or Mozilla Firefox™. Similarly, the operating system may be Microsoft® Windows®, or Linux™. The cross-product of the different combinations of the attributes defines a functional coverage test-space. The test-space comprises a set of coverage tasks, each representing functional requirements to be tested: one requirement per functional attribute, and the requirement is that the functional attribute will exhibit the behavior of the value of the coverage task. The coverage task may be seen as a tuple of one value per attribute. In a functional coverage model in which there are three functional attributes, one having three possible values, the second having two possible values, and the third having ten possible values, the cross-product test-space comprises sixty (60) coverage tasks.
The functional coverage model may further comprise a set of restrictions defining a series of values of different attributes that may not appear together. For example, consider a functional coverage defining two attributes: ACTION and USER. The ACTION attribute may be each of the following values: RETRIEVE, STORE, and MODIFY PERMISSION. The USER attribute may be each of the following values: ADMIN, USER, GUEST. In some cases, a guest user cannot modify permission. A restriction may be defined to indicate that the couple (GUEST, MODIFY PERMISSION) is not a valid couple. The fact that a trace does not comprise an entry covering a coverage task that includes the couple does not affect the functional coverage. In other words, all possible coverage tasks—which together form the maximal possible coverage with respect to a functional coverage—do not include any coverage task that comprises the restricted couple. It will be understood that restrictions may be defined with respect to a combination of values of different attributes, and not necessarily with respect to a complete tuple of values. Furthermore, the restriction may be any constraint on combination of values, which may be represented using a Boolean formula over the functional attributes and associated values.